A2E · Admin & Deployment

Standing it up, keeping it, shipping it forward

What the suite is technically, how state is stored, how to back it up, and exactly what production deployment adds. Written so an administrator can operate the prototype and scope the build.

⚠ Current state

The suite ships today as a client-side prototype — no server, no login, no external calls. It is fully functional for running and reporting a project. Everything under "Deployment-stage roadmap" needs a backend and the owner's accounts.

Architecture

Each screen is a self-contained HTML application. There is no build step and no framework server — open a file and it runs. The suite is a set of linked apps sharing one browser-storage data model:

PM Suite — launcher / front door

PM Platform — writes the shared project state

Exec Deck — reads the shared state, renders slides

Subcontract Manager · Capture · Portfolio Command — module apps

Traceability · Crosswalk · References · Operating Manual — standards & docs

Data & persistence

All project state lives in one browser localStorage key:

key: a2e_pm_platform_v1 · value: JSON project model

The PM Platform reads and writes it; the Exec Deck reads it. It is per-browser and per-origin — not shared between machines or users. There is no server round-trip and no telemetry. See the Data Dictionary for the field-level model.

Running it today

Serve the folder over any static host (or open the files locally). No install, no database.
Use a modern Chromium or Firefox browser; keep the same browser/profile to retain state.
For a shared demo, host the static files behind your own access control (see §07).

Backup & migration

Because state is browser-local, treat backups deliberately. To copy a project between machines, export the a2e_pm_platform_v1 value (from the Reports pack or the browser console) and import it in the target browser. Clearing site data erases the project — back up before you clear. The production backend (§06) removes this constraint by moving state to Postgres.

Source & publishing

The standards data and engine logic derive from Barefootservants2/A2E_ContractOps (private). Assistant access to that repo is read-only — files are built in-project and the owner pushes them. The publishing procedure lives in PUBLISH-TO-GITHUB.md.

The flowdown engine is a verbatim port of the repo's applicability.py over 40 clauses from clause_library.json. eCFR Title 48 is authoritative; the app links out and stores no clause prose.

Deployment-stage roadmap

These require a backend and the owner's accounts — they are out of scope for the client-side prototype:

Live gov feeds — SAM.gov exclusions, eCFR full text, USAspending, GSA CALC via 1102tools MCP

Tool sync — Jira, MS Project, OneNote, Outlook APIs; email listener → daily reports

Backend export — JSON model → Supabase / PostgreSQL REST

Compliance engines — DCAA cost audit, DCMA surveillance, live

Auth & access control

The prototype has no built-in authentication. The owner's requirement for production is a password-gated login with an email confirm/deny approval step. Until that backend exists, restrict access at the hosting layer (a private host, VPN, or basic-auth reverse proxy).

Known limits

State is per-browser; no multi-user or multi-device sync until the backend ships.
No live external API calls from the prototype — all integrations are deployment-stage.
Clause snapshots are not legal ground truth; verify against eCFR Title 48 before any compliance action.
PMBOK ITTO detail is verified per-section on demand from the licensed PDF, not bulk-loaded.